Subject: Another loop prevention scheme down in flames !

From: [email-masked]
Date: Wed, 6 Jul 94 15:52:39 EDT

I thought I would summarize the technical discussion from last week's
AIW 5 session on loop prevention, so there's a written record and for
anyone who wasn't there.  I will also offer a few thoughts about where
we could go from here.  I chose not to mention contributor's names in
this summary for fear of misattribution or omission, but I appreciate
all those who joined in on the discussion of this topic.

We spent about an hour on loop prevention at the AIW in RTP.  I
presented some foils with essentially the same proposal as I posted
to this mailing list on May 17th.  The following list notes
what was new in the presentation:
  - I presented LAN-region-based disabling of TCs as a necessary
    part of the proposal.
  - I stated that the proposal should handle parallel bridges as is.
  - I stated that LAN region id's need to be unique within the entire
    DLSw cloud of current or potential partner relationships.
  - I showed a few more examples than were in the written proposal.

The following suggestions/comments/problems arose from the discussion:
1 - LAN region id's need not be human-administered at any level to get
    the uniqueness qualities we want, and to enable fully automatic
    distribution.  Several people made suggestions of ways to achieve
    uniqueness, e.g., imbedding a MAC address or DLSw node name of the
    distributing node as part of the LAN region id.
2 - The scheme does not take into account any sort of link cost or link
    preference metric in determining which of parallel TCs to disable.
    We should probably add one not only for resolving the rule 3 race
    condition more fairly, but also to handle cases where a sub-optimal
    TC has been operational for a long time before a preferable but
    loop-forming TC is activated.
3 - Delivery of the loop detection UI frame and its response is
    unreliable, so we need to add ways (e.g., retries) to lessen
    the chance of non-delivery.
4 - The proposal only detects loops formed by a maximum of two TCs.
    Larger loops can always be drawn which the defined set of topology
    information exchange does not provide enough information to detect.
    For example (letters are nodes, dots are partner relations):

             A ......... C
             A           C -----|
      |----- A                  |
      |                         |
      |----- B           D -----|
             B        .. D
             B ....   :
                  :   :. E -----|
                  :             |
                  :..... F -----|

I think points 1-3 could be accomodated as refinements to this scheme
which we could work on along with other items that need work.  Point 4,
however, is a fundamental problem which I unfortunately overlooked when
I drew the configurations in which I was trying to detect loops.  I
don't see a simple way to extend the scheme of exchanging topology info
to handle these larger cases.  In the meeting and in the hall afterward,
several general ideas were floated for handling this problem:
  - declare that detecting 2-TC loops is sufficient and continue
    with the current proposal (don't solve bigger loops)
  - exploit any multicast capability of the WAN to send out topology
    information
  - send out some sort of explorer (Paul Brittain called it a "mole")
    frame to find possible loops, rather than the topology info
    exchange method.  If needed, the mole could accumulate a route
    as in source route bridging.
  - take a look at some current 802.1 work extending spanning tree
    to non-fully-meshed topologies
Another possibility, of course, is to go with a centralized rather
than distributed solution, where one node collects topology information,
detects and reports loops.

So, what now?

My feeling at the moment is that our eventual approach must solve the
"big loop" problem, or it won't be worth the work to implement it.
I favor pursuing the mole frame idea.  Depending on how this develops,
we may find it worth while retaining a few elements of my proposal,
namely:
  - checking for loops on a TC rather than circuit basis, when the
    TC is formed and then periodically
  - the LAN region id concept and its distribution
  - disabling TCs with respect to LAN regions
I assume a mole frame would replace the topology exchange and the
loop detection rules I proposed.

As tempting as this problem is, I don't think I can spend time on it
right now.  Perhaps one or more new folks can step forward and move
one of these ideas along.  I think we need a new/revised proposal at
least by the next AIW meeting.

Peter